-
-
Notifications
You must be signed in to change notification settings - Fork 350
require that $schema cannot contain a fragment
#1633
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm surprised to see a PR for this. I didn't think there was a consensus on this issue. The discussion just petered out without a clear resolution. I'm providing a review for this result, but I think we need to make sure this is the resolution we want before merging.
My first thought was that we can't do this because older dialect URIs use fragments, but then I realized I don't really know how this would affect older releases. It's a weird chicken and egg problem. I feel like $schema needs to be consistent across releases because it's what's used to determine which release to use. You don't know what version of $schema to use until you read its value.
I think that leaves us with two options: (1) allow (but discourage) an empty fragment, or (2) acknowledge the historic exceptions to the rule.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be called an "absolute IRI" instead of just an "IRI". Then we don't have to make a normative statement that a fragment isn't allowed because that's part of the definition of "absolute IRI". However, it might be a good idea to clarify that fact since most people think "absolute" just means "non-relative". Which means we shouldn't need to clarify that it mean "containing a scheme" anymore. Maybe something like this would work,
I like option 2 -- it exactly covers what we want to do while accomodating the existence of older drafts.
We should still be able to disallow fragments (even empty ones), while still allowing the use of the draft7 and earlier schemas in a new implementation, even with a restriction in the metaschema itself (e.g. with the pattern keyword) -- as a schema should not be getting validated against a metaschema other than the one specified in the $schema keyword.
We would just need to point out the exception for older schemas, so the implementation doesn't reject the use of an empty fragment before considering if an older draft's semantics should apply.
What kind of change does this PR introduce?
Clarification
Issue & Discussion References
$schema#1590Summary
Adds a requirement to
$schemathat its value cannot contain a fragment. This prevents someone from using a non-canonical IRI in this keyword.Does this PR introduce a breaking change?
Technically, yes, but the likelyhood of people using fragments in
$schemais low (probably non-zero, though).